A multi-carrier wireless communications system includes one or more service nodes. Each service node consists of one or more Radio Network Controllers (RNCs) and may also connect to other service nodes. Each RNC further connects to one or more cells within the service node, where each cell includes a plurality of base stations (BS). Each BS communicates with a plurality of mobiles over multiple carrier frequencies. Optionally, a cell may be divided into sectors so that the same carrier frequency may be used multiples times within the same cell.
Processors inside each of the RNCs collect service measurement data for the mobiles handled by the cells connected to the RNC that includes the respective processor. In addition, the processors inside each of the RNCs collect service measurement data for those mobiles which migrate away from the cells of the RNC including the respective processor to a cell handled by another RNC. Thus, the processors inside each of the RNCs may collect, store, and forward service measurement data for other RNCs of the same service node. In addition, each of the RNCs needs to consolidate service measure data collected by RNCs in others nodes as well as the RNCs in its own node, for reporting.
If one of the mobiles crosses a boundary of one of the service nodes, a mobile transfer occurs where the mobile is handled by another of the service nodes. If a mobile travels along a service node boundary, this transfer may occur at a relatively high frequency and consume an inordinate amount of system resources. This transfer does not generate any revenue for a service provider. The current trend is to increase a size of the service node, thus pushing service node boundaries to regions of less transient mobile traffic. However, increasing the size of the service node also increases a size of the community of RNCs that collect service measurement data for each other. Thus, each of the RNCs must collect an increasing amount of service measurement data as the size of the service node increases.
For example, the number of carriers each of the RNCs in a node must support may increase as node size increases as shown in Table 1 below.
TABLE 1Carriers3 Sector-6 Sector-perCarriers perCarriers perNode SizeRNCRNCRNCx5441,6323,264x + y1,6004,8009,600x + y + z4,00012,00024,000
The variables x, y and z represent natural numbers where x<(x+y)<(x+y+z). The total number of carriers for each of the RNCs includes carriers from other RNCs within the service node that have to be supported. Thus, in a conventional architecture, the number of carriers each of the RNCs supports rapidly grows as the service node size increases. Also, each carrier can have, for example, 3 or 6 sectors, which further increases the number of service measurement data each of the RNCs must support. For example, the last two columns in Table 1 above represent the number of sector-carrier service measurement data each of the RNCs must support for a 3-sector carrier and a 6-sector carrier, respectively.
In addition, customers are progressively requiring a greater number of service measurement data inside each data set per carrier. Table 2 below shows one example of such growth over the years.
TABLE 2Number of ServiceMeasurement dataYearper carrier of RNC20069520082972009349
Service providers may use service measurement data to evaluate performance and optimize parameter settings of both the RNC and the BS. The RNC may directly collect service measurement data from the cells to which the RNC is connected and receive service measurement data for other cells through other RNCs.
Each of the service measurement data may, for example, be 4 bytes in size. Thus, the minimum memory needed for collecting all the service measurement data of table 2 in the 6 sector-carrier RNC of table 1 as node size increases, may be as shown below in Table 3.
TABLE 3Minimum memory forcollecting servicemeasurement data inmegabytes (MB) foreach processor in 6Node SizeYearsector-carrier RNCx20061.3x + y200811.3x + y + z200933.5
The above minimum memory is calculated by multiplying 4 bytes by the number of carriers for a 6 sector-carrier RNC for a given node size and the number of service measurement data per carrier for a given year. For example, for the 6 sector-carrier RNC in the node size x+y+z and the year 2009, the calculation would be 4 bytes*24,000*349≈33.5 MB. In implementation, the needed memory is generally doubled to avoid race conditions during service measurement reporting. Moreover, if the number of service measurement data exceeds a capacity of the RNC, the service measurement data is discarded by the RNC and therefore lost in the conventional architecture. In addition, simply increasing the memory size may be expensive and impractical. Nonetheless, even if the memory size is increased, there may be no assurance that the memory size will be large enough to store all the service measurement data for a given period of time, and therefore, some of the service measurement data may still be lost.
The increase in memory needed at each RNC is just one problem associated with an increase in node size in a conventional architecture. For example, during service measurement data reporting, the data collected for a mobile at a node other than the mobile's original node needs to be consolidated. However, the above-mentioned carrier and service measurement data growths further compound this difficulty. In the conventional architecture, each of the RNCs may be allocated a 7 minute window to collect, forward, and consolidate all service measurement data. However, with the increase in carrier and service measurement data sizes due to the node size increase, the RNCs will not be able complete the reporting within the 7 minute window.
The conventional service measurement data collection described above is conducted at hourly intervals. However, customers have recently been requesting service measurement reports at shorter intervals, such as 15 minutes and 5 minutes. As the conventional architecture requires a 7 minute window to consolidate reports, a shorter collection interval, such as 5 minutes, can not be supported by the conventional architecture.
Both the growth of carrier and service measurement data size will continue. Yet in the conventional architecture, the growth of a service node will become limited by the memory size, processor usage, and a sending time of the RNCs in the service node. Thus, the conventional architecture is not sustainable for future growth and/or may require significant maintenance and upgrade costs.